Development and Maintainance Projects.
(note ... the term "native packages" is explained at the bottom)
Core
Packages needed to create a MeeGo image that boots to a bare X/Wayland screen (with no applications) on a reference device (eg ExoPC). Middleware packages driven by the IVI, Tablet and Handset verticals are in the scope of Core. Reference UXes are not.
Focus is on providing a minimal set of packages to allow a product be built upon. Everything required for compliance and very little more.
"I can build a compliant product from the source released from this area."
Question: How to manage the reference device Hardware Adaptation (HA) without giving special treatment?
Primarily a maintenance project with few native packages.
Tools, build-root and toolchain
Packages needed by developers to compile and create MeeGo images: gcc, spectacle, gdb, make etc.
Note that some tools like mic2 that need to be supported on non-MeeGo platforms (SuSE, Debian, RHEL/Fedora, Ubuntu etc) may be better placed in the 'External Tools' project.
Primarily a maintenance project with few native packages.
Tied tightly to Core release schedules.
Distro : Apps + Surrounds == "MeeGo, the distro"
MeeGo isn't a distro - but for the convenience of the hacking community of users on MeeGo devices it should have one. This area provides packages for apps and upstream libraries required to support them like emacs, vim, python etc. It would be made up from Apps and Surrounds. MeeGo should be the reference to be developing on for MeeGo
Surrounds is primarily a maintenance project with few native packages. Very similar to typical distros.
Apps is primarily a development project with native packages.
Related to Core releases.
SDK
Packages needed to develop Apps for MeeGo.
Primarily a development project with native packages.
Related to Core release schedules.
External Tools and Systems
Packages, documentation and IT information for build and deployment systems/packages used by MeeGo and vendors. Typically intended to run on OSes other than MeeGo. Scope includes OBS, Bugzilla, BOSS, OTS, mic2, REVS, IMG
A mix of maintenance and development packages.
Reference Tablet UX, Handset UX, IVI UX
Packages providing a reference UX layer that can be built on top of the Core. No Core packages can be touched. These projects are intended to be used not just as reference implemenatations but also as reference working models.
Requests and bug-reports to Core from the MeeGo UX project should not be treated any differently to a customer project developing a closed UX.
It would make most sense to develop the UX as an aspect of an integration project.
Primarily a development project with native packages.
They could have an release schedule independent to Core (as a vendor would).
Multiple Hardware Adaptation Projects
Community or openly managed packages needed to adapt or supplement Core to boot and run to the same level as Core on individual devices such as ExoPC, IdeaPad, N9* etc. Working with Core and a suitable CE project would be a good approach that would exercise problems faced by vendors with multiple hardware devices.
A mix of maintenance and development packages.
Integration Projects
Eventually these projects should support MeeGo overall by highlighting and helping to resolve interoperability issues based on different MeeGo releases or form-factors.
Handset Community Edition / CE
Packages from Core, the N9* HA and one (or more) Reference UXes as well as CE-specific packages.
The CE project acts as a 'Reference Vendor' http://mer-l-in.blogspot.com/2011/04/meego-de-that-is-how-you-do-it.html
Tablet Edition
As with the Handset CE but using different HA projects. The ExoPC MeeGo images should be released by this project.
This project too should be contributing to the 'Reference Vendor' concept.
IVI Edition
As with the Tablet Edition but for IVI.
Futures
What else? Well how about some future gazing?
MeeGo Python
A set of packages supported by MeeGo. Device vendors who see the value in QML apps with python as the underlying language may include this in a "Compliant" device under an appropriate "MeeGo" label.
Mini-Glossary
native packages
MeeGo tends to use upstream packages wherever possible; but of course some areas will develop new software - these packages are known as 'native' packages since the code and the packaging are managed at the same time.
Posts
No comments:
Post a Comment